home *** CD-ROM | disk | FTP | other *** search
/ MacFormat 1995 January / macformat-020.iso / Shareware City / Developers / apps.to.go / DTS.Lib / ! Functional Changes next >
Encoding:
Text File  |  1994-05-04  |  12.9 KB  |  289 lines  |  [TEXT/MPS ]
  1. Added a feature to the AppsToGo program editor to assist in setting the
  2. variants for the various controls.  First you have to get to the procID
  3. dialog for a particular control.  (To do this, first select the procID
  4. field of the control, and then press Enter.)  A dialog of the possible
  5. AppsToGo-supplied control types pops up.  (TextEdit, List, CIcon, etc.)
  6.  
  7. If you click on a radio button that is already selected, then another dialog
  8. pops up, showing the variant choices for that procID type.
  9.  
  10. If you click on a control type that has no variants, then the procID is
  11. reset to the base id for that control + the useWFont value.
  12.  
  13. __________
  14.  
  15. Added a feature to the control "key equivs" handling code so that the framework
  16. can automatically open a document window when the control is chosen.  Simply
  17. append the document type to the key equivs field.  For example:
  18.  
  19. 031900,0D1900
  20.  
  21. is used as a key equivalent for enter or return.  If you want this control to then
  22. open a document window tagged 'SAMP', then it would look like:
  23.  
  24. 031900,0D1900,'SAMP'
  25.  
  26. If the control key equiv is pressed, or if the control is clicked on, the designated
  27. document will be automatically opened.
  28.  
  29. __________
  30.  
  31. Changed the framework and the AppsToGo editor to use the min/max fields for TextEdit
  32. controls.  The min field is used for selStart, and the max field is used for selEnd.
  33. This allows you to determine if a TextEdit control should initially have its text
  34. selected or not, without having to write code to do it.
  35.  
  36. __________
  37.  
  38. Fixed double-dispose of a handle problem when saving 'WIND' size to a non-existant
  39. 'WIND' resource.  This only occured when using the AppsToGo editor.
  40.  
  41. __________
  42.  
  43. Added feature in File2.c where if the first character of the enumerated window title
  44. is a space, then it uses the 'WIND' window title instead.  This allows commenting
  45. of document definitions when using the AppsToGo editor.
  46.  
  47. __________
  48.  
  49. Extensively changes ListControl.c to support variable-size cells.  If you want a List
  50. control with variable-size cells, then you need to call CLVInitialize() at some point
  51. prior to creating a variable-size cell list.  You can convert an existing list control
  52. to a variable-size cell list control by calling CLVVariableSizeCells(), which calls
  53. CLVInitialize().
  54.  
  55. Various improvements have been made in the operation of the regular list control.
  56.  
  57. Changed Window2.c to pay attention to bit 14 of the List control mode field.  If this
  58. is set, then it creates the control, and then converts it to a variable-size cell list.
  59.  
  60. __________
  61.  
  62. Where and when DoOpenApplication() is called has changed.  It is now called by the
  63. application in Start.c, and also when AppsToGo tells it to apply changes and restart
  64. the application.  It no longer calls it on an 'oapp' event.
  65.  
  66. __________
  67.  
  68. The Kibitz feature of a document remembering what remote application is was connected to
  69. and launching that remote application when the document is opened has been added to
  70. DTS.Lib.  The calls to manage this that have been added are:
  71.  
  72. void            GetFullPathAndAppName(StringPtr path, StringPtr app);
  73. void            AllowAutoReconnect(FileRecHndl frHndl);
  74. pascal Boolean    AEPortFilter(LocationNamePtr locationName, PortInfoPtr thePortInfo);
  75. OSErr            LaunchRemoteApp(FileRecHndl frHndl);
  76.  
  77. Descriptions of the functions can be found in the header file DTS.Lib.protos.h.
  78.  
  79. The sample application DTS.StyleChat uses this functionality.  Refer to it for how to
  80. use the new calls.
  81.  
  82. __________
  83.  
  84. BAD BUG FIXED!!
  85.  
  86. TreeObj.c could try to fetch a long from an odd address, which causes address errors
  87. on 68000-based machines.  This has been fixed.
  88.  
  89. The odds of this happening weren't too good, and therefore it wasn't caught.  Sorry.
  90.  
  91. DTS.Draw, which is the sample that uses TreeObj the most, has objects whose dataSize
  92. is always even, since it is based on sizeof(theStruct).  Structs are padded to be
  93. even in size.  If the data size is even, then all is well.  If it is odd, then the
  94. child handle table immediately following the data area of the objects is aligned
  95. to odd addresses.  When the handle (long) was fetched, an address error occured.
  96. BlockMove is now used to get the long values, so no address errors occur anymore.
  97.  
  98. __________
  99.  
  100. UnmapMenuItem() has been changed to return an invalid menu item number (32767) if there is
  101. a remapping table, but the remapping table has no entry for the given menu item number.
  102. This prevents accidental overlaping of menu item values.
  103.  
  104. If you either have no table for a particular menu, or if all entries are in the table,
  105. then there is no functional difference.  The only possible difference is if you call it
  106. for a menu item that doesn't exist.  It used to simply return the value that was passed
  107. in, and that value could be used as a valid value.
  108.  
  109. __________
  110.  
  111. The TextEdit control has been revised to support the TSMTE init.  If the TSMTE init
  112. is available, then the TextEdit control can support inline-input of double-byte text.
  113.  
  114. HOWEVER:  You must make a call to the TextEdit control to inform it that you want it
  115.           to use TSMTE, or else you will not get this benefit.  Also, you must register
  116.           and unregister your application with the TextServoces Manager if you want
  117.           to use TSMTE, or else you will crash.
  118.  
  119. Start.c now calls InitTSMAwareApplication() and CloseTSMAwareApplication().  This is done
  120. conditionally -- only if the TSMTE init is available.  As part of the startup code, you
  121. need the following to initialize TSM:
  122.  
  123.     if(CTEUseTSMTE())
  124.         InitTSMAwareApplication();
  125.  
  126. And as part of the shutdown code, you need the following:
  127.  
  128.     if(CTEUseTSMTE())
  129.         CloseTSMAwareApplication();
  130.  
  131. CTEUseTSMTE checks to see if TSMTE is available.  If it is, it returns true.
  132. (It is only available if TSM is available.)  If TSMTE is available, then you
  133. need to register and unregister your application with the TextServices Manager.
  134.  
  135. This is all you need to do to your application to support double-byte inline-input.
  136.  
  137. __________
  138.  
  139. The popup CDEF can't handle negative coordinates.  This meant that popups couldn't be
  140. put in sidebars, as AppsToGo distinguishes location of controls by their coordinates.
  141. (Sidebar controls are offset -16384 horizontally.)
  142.  
  143. CtlHandler.c, Utilities.c, and Window2.c were modified to handle popup controls specially.
  144. The control must first be created to be a problem, and therefore Window2.c keeps track
  145. of the ctlDefProc of popup controls for comparison purposes.  The ctlDefProc is stored
  146. in the global gPopupProc.  CtlHandler.c and Utilities.c look at this golbal and compare
  147. it to the ctlDefProc of the control to be drawn or tracked.  If it matches, the port's
  148. origin is set to 0,0, and the control is offset to that location.  When the drawing or
  149. tracking is completed, everything is restored.
  150.  
  151. This allows the popup control to be positioned in negative coordinate space, but still
  152. operate.
  153.  
  154. __________
  155.  
  156. Two procs (plus 4 fields) have been added to the control style (extension) record.
  157. These procs are for the purpose of custom tracking of the control.  The prototypes are:
  158.  
  159. typedef Boolean (*TrackControlProcPtr)(ControlHandle ctl, short part, EventRecord *event);
  160. typedef Boolean (*ScrollProcPtr)(ControlHandle ctl, short part, short oldVal, short newVal);
  161.  
  162. The TrackControlProcPtr is set to nil, except if the control is a scrollbar.  If it is a
  163. scrollbar, then it is set to the static function (in Window2.c) DefaultScroll().  This
  164. function handles the scrolling in a generic way.  The page and line areas of the scrollbar
  165. scroll by 10 pixels and 1 pixel, respectively.  If you wish, you can set the values to
  166. something else.  The values are stored in the ControlStyleInfo record of the styled control.
  167.  
  168. typedef struct ControlStyleInfo {
  169.     short                ctlID;
  170.     TrackControlProcPtr    trackProc;
  171.     ScrollProcPtr        scrollProc;
  172.     short                hArrowVal;
  173.     short                vArrowVal;
  174.     short                hPageVal;
  175.     short                vPageVal;
  176.     short                fontSize;
  177.     Style                fontStyle;
  178.     Str32                font;
  179.     Str63                keyEquivs;
  180.     Str255                balloonHelp;
  181. } ControlStyleInfo;
  182.  
  183. The initial values are set to 0, and if they are 0, the defaults of 10 and 1 are used.
  184. For scrollbars, the trackProc field is initialized to DefaultScroll().  The scrollProc
  185. field is set to nil.  If you want an opportunity to do something while the scrollbar
  186. is tracking, set the scrollProc field to non-nil.  Your function will be called with
  187. the control, part # (thumb, or whatever), the old control value, and the new control
  188. value.  This should be enough information to determine what you want to do.
  189.  
  190. To set the trackProc, scrollProc, hArrowVal, vArrowVal, hPageVal, or vPageVal fields, you
  191. would add some code to the InitContent() proc for the document.  It would be something like:
  192.  
  193. OSErr    InitContent(FileRecHndl frHndl, WindowPtr window)
  194. {
  195.     OSErr                err;
  196.     ControlHandle        ctl;
  197.     ControlStyleInfo    cinfo;
  198.  
  199.     err = AddControlSet(window, (*frHndl)->fileState.sfType, kwStandardVis, 0, 0, nil);
  200.         /* First, add the controls for this document as defined with AppsToGo. */
  201.  
  202.     if (!err) {                                        /* If all is well... */
  203.         CNum2Ctl(window, kScrollbarID, &ctl);        /* Get the scrollbar handle. */
  204.         if (ctl) {
  205.             if (GetControlStyle(ctl, &cinfo)) {        /* Get the scrollbar info record. */
  206.                 cinfo.scrollProc = YourScrollProc;    /* Set the fields you want. */
  207.                 cinfo.hArrowVal = 2;
  208.                 cinfo.hPageVal  = 20;
  209.                 err = SetControlStyle(ctl, &cinfo);    /* Save the modified record in the control. */
  210.             }
  211.         }
  212.     }
  213.     return(err);
  214. }
  215.  
  216. __________
  217.  
  218. The maxTextLen field of the CTENewInfo structure has an additional meaning.  If the
  219. value is less than 1, then the negative of the value is used, and the destRct, viewRct,
  220. and brdrRct fields are deltas from the control rect, instead of absolute rects.  This
  221. edits better in the AppsToGo editor.  Before, if a TextEdit control's size was changed,
  222. the destRct, viewRct, and brdrRct fields had to be adjusted accordingly.  However, this
  223. was done only if the object was resized with the mouse.  If values were typed in for
  224. the control rect, then it was assumed that these were to be edited individually.  Also,
  225. the rect could be sized with the mouse such that when the other rects were adjusted, they
  226. could end up being empty rects.  This caused incorrect rect values from then on.
  227.  
  228. AppsToGo has been modified to handle both positive and negative values for the maxTextLen
  229. field.  Also, the new method of delta rects is the primary method, and therefore the sign
  230. of the maxTextLen field is actually displayed and interpreted backwards.  For the most part,
  231. this can be ignored.  Here are the rules:
  232.  
  233. If the maxTextLen value in the AppsToGo application editor is greater than 0, then the
  234. destRct, viewRct, and brdrRct values are added to the control rect, and the result is
  235. then used.
  236.  
  237. If the maxTextLen value in the AppsToGo application editor is less than 1, then the
  238. control's destRct, viewRct, and brdrRct fields are absolute rects, and will be used as
  239. they are displayed.  Note that when the framework creates a TextEdit control based on
  240. this definition, it will use the absolute value of the maxTextLen field.
  241.  
  242. __________
  243.  
  244. GetNextWindow (and therefore GetNextDocument) have been modified to return
  245. invisible windows (or documents with invisible windows).  This change was made
  246. to allow kHideOnClose windows to not have to be saved in a global.  You can
  247. access the window or document by calling one of the above functions now, even
  248. if the window is curently hidden.
  249.  
  250. __________
  251.  
  252. The document procs for reading and writing the default document header are no
  253. longer initialized in File2.c.  They are left nil.  This means that you will no
  254. longer get reading and writing the default document header information as a
  255. default behavior.
  256.  
  257.  
  258. HOWEVER:
  259.  
  260. If you call DefaultInitDocument, they are set as they were before.  This means that
  261. if you still want this behavior and you use the hierarchical document package, then
  262. you will still get the benefit of reading and writing the default document header.
  263.  
  264. If you want to use the default document header facilities without the hierarchical
  265. document package, simply initialize the procs for reading and writing the header
  266. yourself in your own document initialization code.  You would add the following
  267. two lines (assuming that the document variable is called frHndl):
  268.  
  269.     (*frHndl)->fileState.readDocumentHeaderProc  = DefaultReadDocumentHeader;
  270.     (*frHndl)->fileState.writeDocumentHeaderProc = DefaultWriteDocumentHeader;
  271.  
  272.  
  273. This will give you the behavior you want.
  274.  
  275. The reason for the change is that some documents want the standard header and some don't.
  276. By explicitly setting them within the framework meant that the code got linked in, even
  277. if you then later set the procs to nil (because you didn't want the header).  This caused
  278. dead code to get linked in.  By assuming that the header isn't going to be used, and by
  279. having the application stating that they will indeed be used, we can prevent this dead
  280. code from getting linked in.
  281.  
  282. Again, if you call DefaultInitDocument, you do indeed get the header information.  This is
  283. done because it isn't a bad assumption to make.  If you are calling DefaultInitDocument,
  284. you want things handled for you, and this would include the header information.  If you are
  285. doing something custom, then you want more control.
  286.  
  287. __________
  288.  
  289.